The present invention is application relates in general to digital telecommunication networks and systems, and is particularly directed to the integration of one or more digital control code-based filtering routines into a test code sequence-based latching loopback mechanism of a digital data device, for reducing and/or preventing a data-induced latching loopback condition.
FIG. 1 diagrammatically illustrates a reduced complexity example of a telecommunications network for delivering digital data service (e.g., 64 Kpbs service) from a remote location to data terminal equipment at a customer (end user) site. The network includes a source of digital communication data, such as a DDS service unit 110, which is coupled to a communication path switch 112, shown as a digital access cross-connect system (DACS), that terminates a xe2x80x98westxe2x80x99 end of a T-carrier link (such as a T-1 fiber optic link) 111. It should be noted that data may be coupled to the end user by way of a variety of data service units, such as but not limited to office channel unit data ports (OCUDP)s, digital signal 0 data ports (DS0DP)s, data service unit data ports (DSUDP)s, digital data service terminals (DDST)s, data service unit/channel service units (DSU/CSU)s, and similar equipment, such as frame relay (FR) equipment with built-in interfaces, shown at 130.
The DACS 112 is operative to steer the (64 Kbps) data stream from the DDS service unit 110 into DS0 channels of the T-carrier link 111 for distribution to remote customers by means of a channel bank 114 that terminates an xe2x80x98eastxe2x80x99 end of the T-1 link 111. For this purpose, the channel bank 114 includes an office channel unit (OCU) 115 that directs a respective DS0 channel over a 64 Kpbs connection 113 to a DSU/CSU 116. The DSU/CSU 116 is coupled over a link 117 to data terminal equipment (DTE) or user interface 118.
When maintenance is required on a data transport connection between the channel bank 114 and the customer""s data terminal equipment 118, it is customary practice to employ a test unit 120 of a network operating center, which provides diagnostic and trouble isolation functions, for transmitting various (in-band) interrogation and test or control code sequences to one or more of the digital data devices installed along the digital data transport path. In the illustrated network, digital data devices 115, 116 monitor the data stream transmitted from the channel bank 114 for the presence of such control code sequences, and respond in accordance with the operational function dictated by a received control code sequence.
Where the test code sequence is defined to invoke a loopback, the digital data device responds by going into the particular type of loopback specified by the loopback control byte sequence. In the network diagram of FIG. 1, non-limiting examples of the loopback of interest include an OCU loopback at data path location 130, a channel loopback at data path location 132, or a DSU loopback at data path location 134. The loopback control code sequences may be defined in accordance with well known network specifications, such as ATandT publication Technical Reference TR 62310 xe2x80x9cDS0 Digital Local Channel Description and Interface Specificationxe2x80x9d, August 1993.
The particular sequences employed have names and abbreviations as described in ANSI T1.107-1995 document and include: Transmission in Progress (xe2x80x9cTIPxe2x80x9d), Loopback Select (xe2x80x9cLSCxe2x80x9d), Loopback Enable (xe2x80x9cLBExe2x80x9d), and Far End Voice (xe2x80x9cFEVxe2x80x9d). Each of these control code sequences is a stream of repeated bytes, where the bytes are predefined. For an illustration of the use of such in-band code sequences to interrogate and/or control the operation of one or more telecommunication services channel units, attention may be directed to the U.S. Patents to S. Killian et al, Nos. 5,390,179 and 5,574,723, entitled: xe2x80x9cRemote Provisioning of Telephone Channel Unit Using Inband Digital Code Sequences Transmitted Over Tandem Link,xe2x80x9d assigned to the assignee of the present application and the disclosures of which are herein incorporated.
FIG. 2 illustrates an example of a typical latching loopback test code sequence 210, that is comprised of a set of repeated individual code sequences, sequentially transmitted as: a TIP sequence 212xe2x80x94a don""t care sequence Xxe2x80x94an LSC sequence 214xe2x80x94a don""t care sequence Xxe2x80x94an LBE sequence 216xe2x80x94a don""t care sequence Xxe2x80x94a FEV sequence 218. The don""t care byte sequences X that are transmitted between the control code sequences 212, 214, 216 and 218 may be of different lengths and have different byte values.
One TIP code sequence is the repeated byte sequence: S0111010, S0111010, . . . , S0111010, where the TIP byte S0111010 is repeated sequentially a prescribed number of times (e.g., at least 35 times). The bit xe2x80x9cSxe2x80x9d is a don""t care (or X) value. Similarly, according to the above-referenced TR 62310 document, the number of LSC bytes in a loopback select sequence may comprise at least 35 bytes; the number of LBE bytes in a loopback enable sequence may comprise at least 100 LBE bytes; and the number of FEV bytes in a far end voice sequence may comprise at least 32 bytes.
FIG. 3 is a state diagram showing the operation of a conventional latching loopback mechanism employed by a currently commercially available digital data device, such as an Adtran D4 OCU DP, manufactured by Adtran Corp., Huntsville, Ala., to respond to the latching loopback code sequence of FIG. 2. FIG. 4 shows a prior art state transition table associated with the state diagram of FIG. 3. As shown in the state diagram of FIG. 2, the digital data device of interest is initially in the monitor state 310.
During the course of the transmission of data over the network, if a prescribed majority M out of N TIP sequence (e.g., M/N=31/32) is detected by the digital data service device""s control processor, a TIP VALID transition 312 is invoked, and the conditional operational state of the device transitions from its initial monitor state 310 to the select state 320. Namely, TIP VALID true means that M (e.g., 31) TIP bytes have been detected within a plurality of N (e.g., 32) sequential bytes being received from the digital data path.
Once in the select state 320, if a prescribed majority M out of N LSC sequence (e.g., M/N=31/32) is detected, an LSC VALID condition 322 is invoked, and the conditional operational state of the device transitions from the select state 320 to the enable state 330. While in the enable state 330, if a prescribed majority M out of LBE sequence (e.g., M/N=93/96) is detected, an LBE VALID transition 332 is invoked, and the device state transitions from the enable state 330 to the FEV state 340. Finally, in the FEV state 340, if a prescribed majority M out of LBE sequence (e.g., M/N=7/8) is detected, an FEV DETECTED condition 342 is invoked, and the device state transitions from the FEV state. 340 to the latching loopback state 350.
In order to exit the latching loopback state 350 (and return to the monitor state 310), a TIP VALID condition 312 must be asserted true, or a manual reset is required. Also shown in the state diagram of FIG. 3 are additional TIP VALID sequence paths 312 emanating from each of intermediate states 320, 330 and 340, and transitioning back to the select state 320. Pursuant to the TR 62310 document, the state diagram of FIG. 3 further contains respective xe2x80x98watchdogxe2x80x99 timer paths 360, for aborting the latching loopback procedure from any of intermediate states 320, 330, and 340, in order to reduce the probability of false loopback sequence detection from the contents of a monitored data stream.
A respective watchdog time path 360 is true (binary xe2x80x981xe2x80x99) when the watchdog timer expires before the next expected byte sequence has been detected. For example, when in the select state 320 the LSC sequence is expected. If LSC VALID 322 is not true after a prescribed period of time (e.g., 25 seconds) a watchdog time-out transition 360 is made back to the monitor state 310. Although the watchdog timer may have different values in each of the states of the state diagram 300, a respective watchdog timer path 360 typically uses the same time-out value for each state.
Historically, at digital communication data rates less than 64 Kbps, only seven out of every eight bits on the network were made available for the transport of customer data; the eighth (unused) data bit was set to a value of xe2x80x981xe2x80x99. Operational and maintenance control mechanisms, such as the loopback mechanism described above, exploited this unused bit data format by using eight bit control sequences (having placing a xe2x80x980xe2x80x99 in the normally unused eighth bit position).
However, as the demand for higher-speed data increased, service providers began furnishing 64 Kbps xe2x80x98clear channelxe2x80x99 service, in which all eight bits of a DS0 channel are employed for the transport of customer data. As a consequence, it is now possible for one or more control codes, including those described above for latching loopback, to be contained in the customer data. Namely, with all eight bits being used for data transport, it is now possible for the data stream itself to unintentionally contain successive xe2x80x98dataxe2x80x99 bytes that cause the activation of an operational condition, such latching loopback, which may result in a corruption or loss of data, (even though the possibility of such an occurrence in a random bit data stream is extremely small).
This may be understood with reference to the frame relay packet diagrams of FIGS. 5 and 6, whose data field may randomly produce the latching loopback test sequence described above. Once it has detected the entire latching loopback test sequence, the responding digital data device will go into a latching loopback state. When the digital data device is in such a latching loopback state, a relay couples a transmitter in the device directly to the receiver of the device. The digital data device is released from the latching loopback mode only in response to receipt of a TIP sequence or by a manual reset procedure.
More particularly, FIG. 5 shows a frame relay packet 230, which is comprised of a leading FLAG byte 232 (7EHEX) followed by a HEADER field 234, a DATA field 232, a CRC field 238, and a packet-terminating FLAG byte 232. The FLAG byte 232, HEADER field 234, and the CRC field are not controlled by the user, but by network elements. However, since the DATA field 236 is user-determined, it is possible for a user to insert, intentionally or accidentally, a file or message containing the latching loopback enable sequence 210 of FIG. 2 within the frame relay packet DATA field, thereby producing a FR packet containing a test sequence 240, as shown in FIG. 6. In this instance, if subsequent user data does not contain a command for exiting the loopback condition (a TIP code sequence), the digital data device that has received the packet 240 will remain in a latched loopback state, until a manual reset occurs, which may require a technician to travel to the location of the digital data device.
As noted earlier, in order to reduce the probability of false loopback sequence detection from the contents of a monitored data stream, section 7.3.2 of the TR 62310 document suggests the use of a watchdog timer, as shown at 360 in the state diagram of FIG. 3. The TR 62310 document additionally specifies that customer equipment xe2x80x9cNOT transmit the loopback test sequencexe2x80x9d, even though such a sequence may in-fact be valid 64 Kbps customer data. As an unintentional latching loopback may occur in the provider""s network, there is a latching loopback problemxe2x80x94which is made even worse when the digital data devices are used in other data services such as frame relay service.
In the case of other data services, the data being transferred over the network may not have entered the network from the same type of service. For example, one network link could be a 64 Kbps DS0 connection and another network link could be a 1.536 Mbps, DS1 connection. Different connections are often used for internet service, where there is little, if any, control over the content of customer data. Indeed, it is possible to produce and send a latching loopback sequence in a single IP/UDP packet, where the sequence could originate anywhere on the internet. When an internet-originated sequence is received by a digital data unit, the digital data unit may become disconnected from the network, and cannot be reconnected until the latching loopback feature is manually disabled.
Were a latching loopback sequence to be transmitted on the internet in a malicious manner to a large number of digital data devices, a significant number of critical network connections could be temporarily disabled. This latching loopback problem can become acute for network operators providing 64 Kbps service, as reported in the Sep. 8, 1997 minutes of the Frame Relay Forum, item 97-077. Unfortunately, the above-referenced watchdog timer method suggested in the TR 62310 document for preventing false loopbacks for 64 kb/s service has been shown (in actual deployment) not to reduce the problem to an acceptable level.
In accordance with the present invention, the inability of a watchdog timer, per se, to significantly reduce the possibility of data induced latching loopbacks is effectively obviated by a new and improved code-based latching loopback control mechanism, which integrates one or more digital control code-based filtering routines into a test code sequence-based latching loopback scheme. As will be described, the filtering routines of the invention include a xe2x80x98garbagexe2x80x99 byte detection routine, a xe2x80x98protected loopbackxe2x80x99 routine, and a xe2x80x98preamblexe2x80x99 routine.
The xe2x80x98garbagexe2x80x99 or xe2x80x98invalidxe2x80x99 byte detection routine is an intra-loopback establishment filtering routine that limits the type of customer data that may be received between sequences of repeated control bytes of a valid latching loopback sequence. The xe2x80x98protected loopbackxe2x80x99 routine is a flag byte-based filtering routine for frame relay data, which is used to controllably disable latching loopback for a prescribed period of time, whenever a predetermined character associated with a frame of 64K frame relay customer data is detected. The xe2x80x98preamblexe2x80x99 routine is a repeated code based-mechanism that allows the timeout invoked in the frame relay protected loopback routine to be controllably terminated, so that latching loopback may be immediately re-enabled.
In accordance with the garbage byte detection routine, the select, enable and far end voice states of a conventional control code sequence-based latching loopback scheme, in addition to invoking a watchdog counter, count the occurrence of invalid (garbage) bytes in the received data stream. An invalid byte is any byte other than the control code pattern of the next expected byte in the latching loopback sequence, or a byte pattern of one or more one byte code exceptions, that have been determined not to have affect the latching loopback mechanism. The number of invalid bytes is compared with a xe2x80x98tolerancexe2x80x99 count associated with the number of invalid bytes that can be received by the digital data services unit without having to abort the latching loopback routine. If the invalid byte count is reached before the next expected byte is validated for a state transition, the loopback routine is aborted.
To implement the loopback protection mechanism, the select, enable and far end voice states of a latching loopback sequence are modified to detect whether a received DS0 byte is a flag byte (7EHEX). If so, the latching loopback sequence is aborted to the monitor state. Once aborted to the monitor state, the ability of the digital data service device to perform a control byte sequence-initiated latching loopback is inhibited for a prescribed period of time, by means of a byte counter which preferably counts received DS0 bytes up to the maximum length of a frame, which for frame relay is 8192 bytes.
To controllably terminate this loopback protection initiated time-out, during the monitor state, the control processor of the digital data service device executes a preamble routine, during which it looks for a valid xe2x80x98preamblexe2x80x99 control code sequence containing a plurality of preamble bytes. A preamble byte may correspond to an idle byte (S1111110), since an idle byte code is not a legitimate byte in random frame relay data. As with the other repeated bytes of a latching loopback sequence, only if a majority M out of N preamble code sequence is detected will a transition from the monitor state to the preamble state be invoked. When a valid preamble sequence has been detected, the DS0 byte counter used for the abort time-out of the loopback protection feature is immediately cleared, which allows the conditional operational state of the device to transition from the monitor state to the preamble state. Once in the preamble state, the latching loopback sequence may be detected.